前面講了好多天「鼠勾以怎麼問」。八大區塊、四種模式、例外情境，一路問下來內容確實越來越完整。但有一個問題從第一版就一直存在。
需求方PM：那我這樣……算問完了嗎？
這句我聽過太多次了，每次都很難回答。因為「夠不夠」是個很主觀的感覺。需求方PM 自己心裡沒底，我在旁邊也只能憑經驗回一句「我覺得差不多了啦」。問題就出在「我覺得」這三個字，它撐不起一份要拿去找 SA 開會的需求。
同一份需求，我覺得夠了，另一個資深一點的同事可能覺得還差得遠。標準留在每個人腦袋裡，而且各不相同。靠感覺判斷「準備好了沒」，結果好壞完全取決於當下是誰在判斷。
我要的是反過來：把「夠不夠」從一種感覺，變成一個看得到、有依據的數字。需求方PM 不用再說「我覺得」，畫面上的資料會直接告訴他這份需求目前到哪了。
所以我做了一個決定：給需求一個分數。 一個 0 到 100 的數字，每答完一個段落就即時更新，每次回覆都掛在對話底下。需求方PM 不用再回頭問「我夠了嗎」，那個數字會直接告訴她。
畫面底下那條狀態欄，長這樣：
📍 區塊 2 目標使用者 (Q1/3) ｜ SA 就緒度：15/100 🌰 安心紮根
一行，每次回覆都更新。需求方PM 隨時瞄一眼就知道自己走到哪、離「可以找 SA」還有多遠。判斷的依據從「資深的人的直覺」變成「螢幕上這個數字」，新手需求方PM 也能自己看著它往前推。
這就是 SA 就緒度。
先講個容易搞混的點。這個分數我刻意不叫「完成度」，叫「SA 就緒度」。
差別在哪？完成度是「問卷填了幾趴」，是站在工具的角度。就緒度是「這份需求拿去找 SA 討論，他能不能順利接住」，是站在 SA 的角度。
這個視角的轉換很重要。因為它直接決定了「哪些題目該佔比較重」。
如果是純粹的完成度，每個區塊平均分配最公平。但對 SA 來說根本不是這樣，他最在意的是功能主軸講不講得清、主流程畫不畫得出來、例外情境有沒有想過。背景故事再動人，少了這三樣，SA 一樣開不下去。
所以我配分的時候做了一件事：把 SA 真正在意的那幾個區塊，權重壓得明顯比較重。 背景、使用者這些「上下文」區塊分數輕一點；功能、流程、例外這些「SA 核心」區塊分數重很多。具體幾分我這邊先不攤開（這算是工具調出來的內部手感），但原則就一句話：分數要往 SA 開會時會卡住的地方傾斜。
這樣一來，那個數字就不只是「進度」，而是「這份需求扛不扛得住 SA 追問」的預估值。
配分的骨架定了，接下來是一個很容易踩到的反直覺陷阱。
我第一版的算法是「答對一題加一點分」，聽起來合理，實際跑起來很快就出問題。
鼠勾以遇到答得模糊的需求方PM 會追問，一個面向追個五六題很常見。但如果「每題」是計分單位，就會出現一個反過來的結果：需求方PM 答得越含糊、被追問越多題、分母就越大，同樣的內容算出來的分數反而越低，等於在懲罰需要多問幾句才講清楚的人。
所以我改成面向完成制。
意思是：計分的單位不是「題」，是「面向」。一個面向不管鼠勾以問了 2 題還是 10 題，只要這個面向最後「確認清楚了」，分數就一次性加上去。追問再多次，都不影響分數，追問只是把同一件事問到清楚而已。
這個改動表面上是算法細節，實際上是在定義這個工具獎勵什麼：分數對應的是把事情想清楚，而不是回答的速度。 一個需求方PM 在某個面向來回問了八次才釐清，不應該因此被扣分，她通常是最認真處理需求的那一種。
這其實對應到心理學家 Carol Dweck 講的「歷程讚美」（process praise）。她那個很有名的五年級生實驗（Mueller & Dweck, 1998）發現：被稱讚「你一定很努力」的孩子，比被稱讚「你很聰明」的孩子，後續更願意挑戰難題、也更耐挫。被讚天賦的那組，反而會為了維持「我很聰明」的形象，選簡單的題目避免出錯。面向完成制獎勵的是「把它想清楚的過程」，不是「你一次就答對的天分」，走的是同一個方向。
順便還解掉一個老問題：需求方PM 答「不確定」「之後再問」的時候怎麼算？很簡單，那個面向就是沒完成，不計分，但會被丟進「待確認清單」。不灌水、也不漏接。
分數有了、算法也穩了，照理說可以收工。但只丟一個數字給需求方PM，效果並不好。
77 分這個數字本身不帶任何訊息，讀起來甚至有點像考績。被打分數對很多人是有壓力的，需求釐清本來就讓人不安，再加一個分數可能只是讓人更焦慮。
我要的效果剛好相反：這個分數要讓人想繼續往下走。
於是有了 10 級成長標籤。我把 0 到 100 切成十段，每一段配一個「需求樹」的成長階段，分數越高、樹長得越大：
| 分數 | 成長標籤 |
|---|---|
| 0–9 | 🌰 種子入土 |
| 10–19 | 🌰 安心紮根 |
| 20–29 | 🌱 冒出新芽 |
| 30–39 | 🌱 小芽長高 |
| 40–49 | 🌿 葉子展開 |
| 50–59 | 🌿 枝葉茂盛 |
| 60–69 | 🌼 花苞出現 |
| 70–79 | 🌼 快要開花 |
| 80–89 | 🌻 需求盛開 |
| 90–100 | 🌳 果實成熟 |
這其實就是一種遊戲化（gamification）。電玩裡的經驗條、養成遊戲裡慢慢長大的寵物，用的是同一招：把抽象的進度，包裝成一個「會成長的東西」，讓你想看著它變大。我只是把這招借來種需求樹而已。
效果差在哪？同樣 77 分，畫面上配的那行字從赤裸的「77」換成了「🌼 快要開花」。意思就變了：它從「你考了 77」，變成「你種的這棵需求樹快開花了，再澆幾次水就成熟」。
這背後是我刻意挑的設計取向，這裡用優缺點攤開來看比較清楚。
優點：直覺，一眼知道好壞。很多儀表板都這樣做。
缺點：
優點：
缺點：要維護一整套成長文案，成本比放三顆燈高不少，但這部分我評估過是划算的。
說到底，需求釐清本來就是一件容易讓人想放棄的事。一個會讓人想繼續的分數，比一個「精準但冷漠」的分數有用太多了。
上面這幾個設計都不是憑感覺決定的，每一項都能對到行為心理學裡被反覆驗證過的效應。以下把設計和對應的研究列在一起。
「分數越高、越想衝完」靠的是目標梯度效應（Goal-Gradient Effect）。 這效應最早在 1932 年由心理學家 Hull 從動物學習研究裡提出，後來 Kivetz、Urminsky 和 Zheng（2006）在人身上做了驗證：集點卡越接近兌換門檻，消費者買得越勤。把分數即時掛在對話底下，就是想借這股「快到了，再撐一下」的勁。
「一開始就給一個標籤、不從空白起跳」靠的是稟賦進步效應（Endowed Progress Effect）。 Nunes 和 Drèze（2006）做過一個洗車集點實驗：同樣要再蓋 8 格，拿到「已經幫你蓋好 2 格」的 10 格卡的人，比拿空白 8 格卡的人完成率更高、也集得更快，明明要買的次數一模一樣。所以需求方PM 才剛開始答，就已經是「🌰 種子入土」，而不是冷冰冰的 0。起步就有東西，人才比較捨不得放掉。
「養成系的成長樹」本質是遊戲化，底層是自我決定論（Self-Determination Theory）。 Deci 和 Ryan 講人有三個基本心理需求，其中一個是「勝任感」，看到自己在變強。一棵會長大的需求樹，餵的就是這個。加上蔡格尼效應（Zeigarnik Effect）：沒做完的事會在腦中留一股張力，一條沒填滿的進度條，會讓人有點想把它填滿。
知道這些理論，最實際的幫助是調整時有依據：標籤該切幾級、起步要不要先給分、進度條擺哪裡，都可以回頭對照原理判斷，不必每改一版就丟給需求方PM 試一次。
最後講一個我自己搞混過、後來特地寫進規則的細節。
成長標籤旁邊都帶著一個 emoji（🌱🌿🌼）。有一版我判斷進度條上已經有 🌱，正向回饋應該夠了，就把區塊完成、分數里程碑的那些鼓勵語都省掉。
實測的結果是整段對話都變得很平。需求方PM 答完一整個區塊，畫面上只多了一行進度條，那個 🌱 變成純裝飾，沒有人會因為一個小圖示覺得被鼓勵。
我才意識到自己把三件事搞混了。後來在規則裡把它們切得很乾淨：
進度條尾巴的成長 emoji，只負責「進度視覺化」，它就是個狀態指示燈，不算鼓勵。區塊完成時的「需求樹長高了」那種回饋，是針對「你完成了一個段落」。而真正的鼓勵語，是分數跨過某個里程碑、跳到下一個成長標籤時才送出的。三者分工，誰都不能頂替誰。
這個細節本身不大，但它說明了一件事：需求方PM 答完一整個區塊之後想看到的是「有人注意到她完成了」，一個圖示提供不了這個。該給的回饋還是要用文字寫出來。
寫到這裡都還是當初的設計。後來這套評分出了一個問題，得補講一下。
原本分數本身就是門檻。就緒度到 60 以上，鼠勾以的話術會變成「你可以拿這份去找 SA 討論細節了」。我設計的時候想得很直觀：100 分制嘛，60 分及格。
問題是「60 分的需求長什麼樣」，我一開始沒有認真看過。後來翻了幾份，大概是這樣：主流程有了，例外情境空著三四個面向，業務規則裡留著兩三個「再議」。這種需求拿去約 SA，SA 一定先問那幾個空著的地方，需求方PM 答不出來，散會，回家補，再約一次。這不就是 Day 2 那場失敗會議嗎？我做這個工具就是為了消滅那種會，結果工具自己在 60 分就跟人家說「可以去了」。
所以後來改成：分數繼續顯示，但它只代表進度；放行與否另外判斷，條件叫「達標」。定義是兩條：
第二條需要解釋一下。待確認清單本來就有一個「負責確認單位」欄位，記這件事要回去問誰。我直接重用這個欄位來判斷：要問工程的、要問 SA 的、要問法遵的，都不擋達標，因為需求釐清沒有要需求方PM 假裝懂技術，「API 規格我要回去問工程」是一個完全合格的答案。擋達標的只有一種情況：這個欄位填的是需求方PM 自己。像「逾期的點數要不要退」，這是業務決策，需求方PM 不決定就沒有人能決定，這種題留著，需求就是沒好。
沒達標硬要產出的話，鼠勾以會先把缺的東西列出來，問一次要不要補完。不補的話文件還是會給，但會是 0.9 草稿版，開頭直接標示這是草稿、缺哪些東西，達標之後產的才是 1.0 正式版。會留這個後門是因為需求方PM 有時候真的有時程壓力，需要先拿個半成品去跟主管交代進度，把門鎖死只會逼她回去用 Word 自己亂寫一份。
改完之後我做了一輪紙上模擬，設計十種不同個性的使用者來測這個工具：急性子、話多的、沒自信的新手、敷衍型都跑了一遍。敷衍型這一關沒過：既然「推給別人不擋達標」，每一題都答「這要問工程」就能拿到 100%。後來的補法是把問題分成四類（業務決策、技術事實、系統設計、政策合規），業務決策類的題答「不確定」時，鼠勾以會先追問一次，追問完還是不確定，這題的負責人仍然填需求方PM，不會因為她嘴上說「問工程」就真的轉給工程。
分數有了、標籤有了，但每次回覆都把一整張進度大表貼出來，對話會被洗版洗到很難讀。怎麼讓需求方PM 隨時看得到分數、又不被表格淹沒？下一篇講「兩層式進度顯示」：什麼時候只給一行精簡進度條，什麼時候才展開完整表格。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術